As computing power continues to increase, operating systems supporting various software applications have also been able to increase in sophistication and complexity, resulting in the support of multi-tasking environments.
With the introduction of virtualisation, a virtual machine environment has been introduced into computer systems between hardware and the operating system. This virtual machine environment is able to support multiple operating systems, and has the ability to allow software to be partitioned into virtual systems so that the software running on one virtual system, within one partition, is not able to influence software of another virtual system on another partition.
These virtualisation techniques have been recently implemented within embedded computing systems, such as multi-core microcontroller units (multi core MCUs) or powerful single core MCUs.
Referring to FIG. 1, a block diagram of a known multi-core processing device 100 is illustrated. The known multi-core processing device 100 illustrates a software region 130 and a hardware region 140. The known multi-core processing device 100 comprises a first processing core 102 and a second processing core 104, wherein the first processing core 102 supports software running on a first partition 106 and the second processing core 104 supports software running on a second partition 108. In the hardware region 140, only the cores execute the whole software.
A virtual machine monitor, such as a hypervisor 110, is part of the software section and located between the partitions 106, 108 and the respective cores 102, 104 in order to support communications between them. The hypervisor 110 acts as a separate logical entity, but is physically part of the controlled partitions and executed by the core(s) 102, 104. A bus 112 is used to interface the cores 102, 104 with other elements of the system (not shown).
Generally, locally received data frames will be generated by the hypervisor 110, and the hypervisor 110 is responsible for management of shared transmission and reception resources, which may include interrupt generation of processing cores and/or override handling.
A communication controller 114, comprising a host controller interface 116, protocol engine 118 and data buffers 120 operably connected, is implemented to control aspects of the known multi-core processing device 100.
For independent activity of the separate first and second partitions 106, 108, concurrently used peripherals, (not shown) coupled to the multi-core processing device 100 via a bus 122, must be virtualised. Although this known multi-core processing device 100 describes a two partition configuration, for explanatory purposes, any number of partitions and number of cores (e.g. one to many cores) may be supported.
Generally, the communication controller 114 must be virtualised in order to support independent activity of the separate partitions 106, 108. This is a resource intensive software task for the hypervisor 110, particularly if inter-partition communication, or worse inter-core communication, is required.
The hypervisor 110 must intercept all accesses on concurrently used peripherals that could cause concurrent interference issues. The risk of interference is possible if more than one partition accesses the same resource at, or close to, the same time. In order to prevent the risk of interference, the hypervisor 110 must serialise the accesses by applying delayed time-controlled and/or event-controlled activities to maintain synchronicity of all communication partners.
It is known that local communication between partitions 106 and 108 requires the hypervisor 110 to emulate the whole or a majority of the host controller interface 116, residing within the communication controller 114, if partitions 106 and 108 utilize the same bus 122. The emulation of the host controller interface 116 generally requires a large amount of resources.
In the case of fan out of a received datagram (necessary if partitions 106 and 108 utilize the same bus 122), the hypervisor 110 must multiply host controller interface 116 information including: reception status, raising multiple interrupts, maintaining interrupt status for each partition, and emulate received datagrams by preserving correct timing and/or correct synchronicity.
Referring to FIG. 2, a known operation 200 of parts of the multi-core processing device 100 of FIG. 1, namely the communication controller 114 and hypervisor 110, is illustrated. Typically, an incoming data stream 202 is received by the communication controller 114 and subsequently decoded at 204 by a protocol engine to provide a datagram. The protocol engine buffers the decoded data stream until a complete datagram is created 206. At 208, the protocol engine notifies a host controller interface (HCI), which subsequently registers and outputs a receive interrupt at 210. With this in mind, it is worth confirming that the term ‘interface’, with reference to a HCI, is somewhat of a misnomer, as the HCI is a little less complex than the protocol engine. The HCI maintains status information, decodes commands and often also implements state machines for serving complex data exchange protocols (even for host-controller communication). The HCI must cover two tasks: enable data flow and provide capabilities for data flow control.
The hypervisor 110 catches the HCI generated interrupt at 212 and subsequently makes two copies of the received datagram at 214. At 216, the hypervisor 110 raises two emulated receive interrupts, and, at 218, the hypervisor 110 releases the received interrupts. At 220, the applications within the first partition 102 and second partition 104 handle their respectively received interrupts from the hypervisor 110.
Thus, the virtualisation of communication controller 114 is a resource intensive software task for the hypervisor 110, especially if inter-partition communication is required, or worse inter-core communication is required, as the hypervisor 110 is responsible for generating locally received data frames and management of shared transmission and reception resources, such as interrupt generation and override handling.
In this case, the hypervisor 110 is required to copy, emulate and release two copies of the received interrupt for the first partition 102 and second partition 104. If further partitions were implemented, even more copy, emulate and release steps would be required, further stretching the resources of the hypervisor 110 and the processing device 100.